qa(checklist): write-feedback acceptance[1] states the record-level vs singleton / named-automation boundary - #26185

Requested by Steve · project thread
Fixes #25849
Clause-②: no
Metadata-protocol: none

The fifth line of the card: ux-conventions.write-feedback acceptance[1] reworded to the maintainer's ruling, comment 6417978207 on the card, letter C. Wave anchor: #25807 (linked only; it stays open). The other four lines of the card landed in #26109; the ui half of the ruling is its own card #26172, which this PR does not wait for: the clause defines the test, the ui card makes the console pass it.

Docs only: one ledger file, one item. Nothing under packages/, ui/ or any governed surface moves, so the PR carries skip-changeset.

What changed

docs/qa/platform-checklist/areas/ux-conventions.json, item ux-conventions.write-feedback only:

• acceptance[1] clause states the boundary the ruling draws: a record-level write names the record (title / display name) or the count; a singleton page (settings) and a named automation are their own subject and pass as they are; a bare Success / Done or a machine name still fails.
• acceptance[1] verify is a two-step, decidable test: classify the row first (record-level, or singleton / named automation), then score it by that class's test. A record-level row that names only the object ("Task created successfully") scores FAIL and cites Record create/update success toasts name the record by its title, not only the object (ruling C on #25849) #26172.
• revision 5 → 6; one history row citing the card, the ruling comment 6417978207 and QA run QA run · release-18.2.0-manual-set (29/29) · 6679644a · 2026-10-25 · 25 PASS / 4 PARTIAL / 0 FAIL / 0 BLOCKED / 0 NOT-RUN #25817 (ref is the card, as the revision-5 row of the same card is).

Before (origin/main c7aa9cd)

clause: success feedback names what changed — the record, item or count — rather than a bare 'Success' or a machine name

verify: read the captured text: it names the subject (record title, invitee email, package label, 'N created · M skipped'); a generic 'Done' / 'Success' or a raw snake_case name scores FAIL for that row

After (fa4e25d)

clause: success feedback names its subject: a record-level write names the record or item (its title, label or display name) or the count; a singleton page (settings) and a named automation (e.g. Flow "X" completed) are their own subject and pass as they are; a bare 'Success' / 'Done' or a machine name never passes

verify: two steps per row. First classify the write: record-level (a record create, edit or delete, the import, the approval decision, a record or param action, a Studio item) or singleton / named automation (the settings save, a named Flow run). Then score it by that class's test. Record-level: PASS when the captured text names the record or item (record title or display name, invitee email, package or item label, e.g. 'Approved "EXP-2001"') or the count ('N created · M skipped', '1 row saved'); text that names only the object ('Task created successfully') scores FAIL — the console's record create and edit toasts read that way until ui card #26172 lands, so those rows are expected FAILs that cite it. Singleton / named automation: PASS when the text names that page or automation ('Settings saved', 'Flow "Reassign Task" completed'). In either class a generic 'Done' / 'Success' or a raw snake_case name scores FAIL for that row

Verification

• Scripted span edit (each anchor hit exactly once); a value comparison proves the new document equals the old one plus the four declared operations, the other two items of the file value-equal, and the bytes outside the edited spans unchanged (git diff: +9 / −3).
• pnpm check:platform-checklist at fa4e25d: exit 0, OK — 16 areas, 329 items (324 active, 1 planned).
• dispatch-gates --commands derives 13 families for this diff; all 13 run at fa4e25d, every one exit 0; --ran reconciliation: 13 derived, 13 run, 0 NOT-MEASURED, 0 UNRUN.

Acceptance notes

• The record-level class keeps the original clause's "item" (Studio rows are named by the item label) so the Studio autosave / publish / discard variants still have a class; the ruling's own words name records, settings and named automations only.

Generated by Claude Code